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1.0  INTRODUCTION 

In  September  1983,  the  Methodology  Coordination  Team  (MCT) 
began  addressing  the  comments  made  on  the  METHODMAN  document 
prepared  by  Peter  Freeman  and  Anthony  Wasserman  (1).  These 
comments  included: 

•  only  "traditional”  methodologies  were  addressed 

•  it  focused  primarily  on  the  development  part  of  the 
software  life  cycle, 

e  no  relationship  was  established  to  the  emerging  DoD 
software  life  cycle  defined  in  DoD-STD-SDS, 

•  the  set  of  characteristics  given  for  classifying 
software  methodologies  was  incomplete  and  many  of  the 
identified  characteristics  were  not  concrete  enough  to 
be  measured, 

•  the  organization  of  the  set  of  characteristics  was  ad 
hoc,  and 

•  the  requirements  given  for  Ada*-compatible 

methodologies  were  too  general  and  not  specifically 
related  to  the  characteristics. 

In  addressing  these  comments,  the  MCT  focused  its  attention  on  two 
major  issues:  (1)  software  development  and  'maintenance'  life 
cycle  and  (2)  an  approach  to  classifying,  evaluating  and  helping 
people  to  select  methodologies.  This  report  is  a  summary  of  the 
initial  work  of  the  MCT  on  these  issues. 


Basic  concepts  of  software  ere 
identified  in  Section  2.  The  use 
accumulation  and  analysis  are  discussed 
risk,  uncertainty  and  complexity  associ 
projects.  Different  types  of  software 
and  the  general  nature  of  the  methodol 
with  each  are  discussed.  The  concept 
and  then  used  to  identify  the  spectrum  o 
creating  and  evolving  various  types 
concept  of  using  specific  methods  or 
organize  and  discipline  these  activi 
several  different  types  of  methodologies 


ation  and  evolution  are 
of  modeling,  Information 
as  ways  of  coping  with  the 
ated  with  most  software 
versions  are  distinguished 
ogical  issues  associated 
of  a  life  cycle  is  defined 
f  activities  involved  in 
of  software  versions.  The 
general  methodologies  to 
ties  is  then  discussed  and 
are  distinguished. 


Ada  is  a  registered  trademark  of  the  U.S.  Department  of 
Defense  (Ada  Joint  Program  Office) 


Finally,  the  prospects  for  covering  a  broad  spectrum  of  activities 
by  using  several  compatible  methodologies  are  discussed.** 

In  Section  3,  the  problem  of  evaluating  and  selecting  among 
alternative  methodologies  is  addressed.  The  need  for  technologies 
to  support  the  classification  and  evaluation  of  specific 
methodologies  and  the  selection  of  a  methodology  from  among 
alternatives  is  established.  Interrelationships  among  these 
technologies  are  addressed,  as  is  the  process  of  co-evolving 
them.  The  intertwined  roles  of  selection  criteria,  evaluation 
measures  and  classification  metrics  are  discussed.  Finally,  the 
discussion  establishes  the  critical  need  for  detailed  methodology 
characteristics  supporting  the  definition  of  criteria,  measures 
and  metrics  and  therefore  the  classification,  evaluation  and 
selection  technologies. 

A  means  of  organizing  the  potentially  very  large  set  of 
detailed  characteristics  is  the  subject  of  Section  4.  A 
preliminary  framework  is  proposed  for  organizing  the 
characteristics  such  that  one  can  identify  a  subset  of 
characteristics  pertinent  to  a  general  area  of  methodological 
concern,  a  specific  type  of  software  version  or  a  general 
methodology.  The  framework  specifies  a  way  of  further  organl zirg 
any  subset  of  characteristics,  in  particular,  subsets  identified 
by  using  the  gross  structural  framework.  The  framework  is 
specifically  designed  to  be  extensible  and  this  aspect  is 
discussed.  In  addition,  a  procedure  is  presented  for  enumerating 
characteristics  to  provide  an  initial  population  which  could  then 
be  refined  and  elaborated  through  further  use  of  the  enumeration 
procedure  or  other  procedures. 


The  sco 
is  prelimina 
attention  to 
the  products 
encompass  not 
myriad  other 
project  as  we 
as  part  of 
necessity,  de 


pe  of  the  work  presented  here  is  broad  and  its  nature 
ry.  It  is  intended  to  give  direct  and  balanced 
both  the  software  creation  and  evolution  process  and 
produced  during  this  process.  It  is  also  intended  to 
only  software  programs  themselves  but  also  all  the 
documents  and  products  produced  during  a  softare 
11  as  the  activities  concerning  the  role  of  software 
some  automated  system.  While  the  work  has  been,  of 
veloped  in  the  context  of  extant  methodologies,  an 


Throughout  this  report,  and  particularly  in  Section  2,  care 
is  taken  to  establish  a  well-defined  terminology.  A 
glossary  appears  as  Appendix  A.  In  preparing  definitions 
the  IEEE  Glossary  of  Software  Engineering  (2),  and  other 
glossaries,  were  consulted.  Our  definitions  deviate  from 
these  already  established  definitions  whenever  it  was  felt 
necessary. 


-  ...  •  j  «r.  t-«-  p  , 


attempt  has  been  made  to  provide  a  groundwork  which  is  flexible 
enough  to  accommodate  future  improvements  in  software  methodology 
as  they  appear.  Overall,  the  work  is  intended  to  be  a 
preliminary,  malleable  step  toward  obtaining  and  using  the 
specific  algorithms,  metrics,  attributes  and  data  that  can  be 
expected  in  the  future. 
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2.0  SOFTWARE  METHODOLOGY  CONCEPTS 


Discussions  of  software  methodology  are  often  plagued  by 
confusion  and  misunderstanding  because  of  differing  perceptions  and 
experiences.  For  example,  software  developers  and  project  managers 
usually  have  quite  different  views  of  the  software  creation  and 
evolution  process  because  of  the  different  activities  they  see  as 
making  up  the  process  and  the  quite  different  concerns  they  must 
address.  The  situation  is  often  complicated,  as  with  many  aspects 
of  computer  science,  by  a  lack  of  a  widely-used,  consistent 
terminology . 

Terminology  and  a  way  of  thinking  about  the  software  creation 
and  evolution  process  are  presented  in  this  section  to  provide  a 
conceptual  basis  for  subsequent  discussion  of  methodological 
issues.  The  way  of  thinking  attempts  to  focus  on  the  process 
itself  as  well  as  on  the  products  produced  as  a  result  of  the 
process,  to  be  pertinent  to  new  approaches  as  well  as  those 
currently  in  vogue,  and  to  tie  the  issues  of  software  creation  and 
evolution  into  the  larger  problem  of  creating  and  evolving  the 
automated  system  of  which  the  software  is  a  part. 

The  following  statements  provide  a  quick  synopsis  of  the 
conceptual  basis  and  terminology  introduced  in  this  section: 

1.  A  software  method  is  a  disciplined  process  for  producing 
software.  It  assists  in  coping  with  the  high  levels  of 
uncertainty,  complexity  and  risk  that  surround  most 
software  projects.  The  majority  of  current  software 
methods  rely  on  modeling,  information  accumulation  and 
analysis  techniques  to  provide  this  assistance. 

2.  A  software  methodology  is  a  collection  of  methods.  The 
collection  may  serve  to  highlight  those  aspects  common 
to  all  the  methods.  Or  it  may  serve  to  define  an 
approach  to  software  development  and  post-deployment 
support  which  is  broader  in  life  cycle  coverage  than  any 
of  the  methods.  In  either  case,  a  specification  for  the 
methodology  defines  those  general  principles,  practices 
and  procedures  shared  by  all  of  the  methods  rather  than 
the  specific  details  peculiar  to  any  particular  method. 
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There  are  several  levels  of  concern  when  considering 
software  methodologies.  These  range  from  the  software 
being  one  part  of  an  automated  system  to  the  software 
being  an  object  undergoing  change  to  correct 
deficiencies  or  enhance  its  capabilities.  Methodological 
concerns  vary  across  these  levels. 

The  software  life  cycle  organizes  the  activities 
performed  during  software  development  and  post- 
deployment  support.  The  phases  of  a  life  cycle  differ, 
in  terms  of  the  emphasis  on  the  activities  involved, 
across  the  levels  of  concern. 

Product-oriented  methodologies  organize  development  and 
post-deployment  support  activities,  each  emphasizing  the 
production  of  (intermediate  or  final)  products  needed  to 
achieve  some  milestone.  Other  types  of  methodologies 
reflect  other  approaches  such  as  developing  a  sequence 
of  gradually  more  mature  versions. 


2.1  Basic  Concepts 

Software  creation  and  evolution  involves  the  preparation  of 
various  products  by  following  some  process.  One  product  is  the 
software's  code,  that  is,  its  executable  version.  Other,  equally 
important,  products  are  designs  and  specifications  for  the 
software,  users'  manuals,  test  case  definitions  and  results,  and 
project  histories  (currently  prepared  in  document  form).  In  this 
report,  the  term  software  refers  to  all  such  products,  not  just  the 
executable  code. 


Most  DoD  software  systems  have  a  level  of  complexity  that  is 
almost  overwhelming.  In  addition,  creating  or  evolving  the 
software  system  is  often  a  high-risk  activity  because  the  software 
is  frequently  targeted  for  use  in  an  application  where  little 
experience  exists  to  indicate  whether  an  acceptable  result  can  be 
obtained  in  a  meaningful  time  period  and  with  a  reasonable 
expenditure.  This  risk  is  accompanied  by  a  high  level  of 
uncertainty  about  the  system's  functionality  and  performance,  an 
uncertainty  that  persists  at  least  until  the  software  is 
implemented  and  can  be  tested  in  its  operational  environment. 
There  are  many  techniques  for  coping  with  this  complexity, 
uncertainty  and  risk.  Current  approaches  to  software  creation  and 
evolution  tend  to  emphasize  three  techniques:  modeling,  information 
accumulation  and  analysis. 

Every  product  of  the  software  development  process,  except  the 
software's  executable  load  module,  is  a  model ,  that  is,  an  abstract 
description  not  containing  all  of  the  details.  The  obvious  benefit 
of  a  model  is  that  it  helps  in  coping  with  complexity  by 
highlighting  pertinent  aspects  of  the  software.  Models  also  aid  in 


coping  with  riak  since  they  provide  points  which  can  be  returned  to 
should  errors  occur  when 


determining  the  details.  Risk  can  be  addressed  by  gradually  and 
rationally  elaborating  the  details  of  a  software  system  in  a  way 
that  supports  periodic  assessment  of  progress,  that  is,  by 
following  a  process  of  information  accumulation .  This  process 
can  vary  from  being  informal  and  intuition-based  to  being 
rigorously  defined  in  terms  of  specific  activities,  techniques, 
work  products  and  reviews.  Finally,  analysis  is  the  process  of 
assessing  the  software's  suitability  and,  as  such,  primarily 
addresses  the  uncertainty  problem.  Techniques  for  incrementally 
testing  portions  of  a  software  system  as  they  are  constructed  are 
prime  examples. 

Modeling,  information  accumulation  and  analysis  provide  a 
strategic  basis  for  coping  with  complexity,  uncertainty  and  risk. 
These  and  other  techniques  require  the  use  of  software  technology 
and  software  methodology.  Software  technology  provides  basic 
techniques  for  accumulating  information  as  a  series  of  well-defined 
models  that  can  be  analyzed  before  the  software  is  fully 
operational.  Software  methodology  imposes  the  discipline  making 
the  overall  process  orderly  and  ensuring  smooth  and  steady 
progress.  It  also  helps  assure  that  project  resources  are 

appropriately  used  so  as  to  arrive  at  closure  on  time  and  within 
budget . 

Software  technology  and  software  methodology  are  highly 
interrelated,  with  the  details  of  each  having  a  strong  impact  on 
the  other.  Consequently,  while  focusing  on  software  methodology, 
it  1 8  Important  to  realize  that  fully  working  out  the  details  of  a 
particular  approach  to  disciplining  the  process  requires 
identification  of  the  software  technology  which  supports,  and 
complements,  the  approach. 

2.2  Software  Versions  and  Levels  of  Concern 

Software  must  be  frequently  changed  to  accommodate  changes  in 
requirements,  repair  errors,  or  upgrade  quality.  This  leads  to 
several  versions  of  the  software  existing  over  time.  Some  of  these 
versions  are  transient  attempts  to  meet  the  requirements  while 
others  have  relatively  long  lifetimes  of  operational  service. 
Versions  actually  placed  into  service  may  reflect  relatively  minor 
modification  or  they  may  reflect  the  major  modifications  needed  to 
provide  similar  functionality  in  totally  different  operational 
situations . 

Three  major  categories  of  versions  are  of  interest  because 
they  relate  to  different  sorts  of  methodological  concerns.  A 
software  system  is  a  version  which  delivers  a  capability  in  a  form 
appropriate  for  Integration  with  other  components  to  create  an 
automated  system.  For  example,  different  software  systems  may 


deliver  a  flight  control  capability  for  different  types  of 
aircraft.  A  software  release  is  a  version  of  a  software  system 
that  is  incorporated  into  and  supported  as  part  of  an  operational 
automated  system.  Each  release  is  intended  to  meet  the  software 
system's  requirements  and  new  releases  appear  primarily  because  of 
changes  to  the  required  functionality  and  performance  or 
corrections  to  remove  errors  discovered  during  operational  use.  A 
software  variant  is  a  (perhaps  incomplete)  version  of  a  software 
release  that  is  an  (perhaps  incorrect)  attempt  to  meet  a  release's 
set  of  requirements.  Successive  variants  may  reflect  design  and 
implementation  changes  made  to  bring  the  software  into  closer 
conformance  to  the  release's  set  of  requirements. 

These  three  major  categories  are  hierarchically  related.  A 
release  encompasses  a  sequence  of  variants,  each  being  a  more 
suitable  attempt  to  meet  the  requirements  established  for  the 
release.  Similarly,  a  software  system  encompasses  a  sequence  of 
releases  meeting  the  changing  requirements  levied  by  the  software 
system's  operational  environment. 

This  distinction  of  three  levels  of  software  versions 
delineates  three  levels  of  concern  for  organizing  and  disciplining 
the  process  of  software  creation  and  evolution. 

Corresponding  to  the  highest  level  (software  systems)  are  the 
overall  concerns  of  how  software  fits  into  the  automated  system  of 
which  it  i 8  a  part.  The  process  of  software  creation  and  evolution 
at  this  level  must  account  for  activities  such  as:  pre-software 
definition  and  design  of  the  automated  system  Itself,  making 
tradeoff  decisions  concerning  which  components  will  be  realized  in 
software.  Integration  of  the  separately  created  and  evolved 
components,  upgrading  the  requirements  levied  against  a  software 
system,  and  demonstrating  the  software  system's  validity  in  terms 
of  meeting  recognized  needs. 

Corresponding  to  the  intermediate  level  (software  releases) 
are  the  project  management  concerns  of  delivering  a  capability  on 
time  and  within  budget.  The  process  at  this  level  must  account  for 
activities  such  as:  deciding  when  a  new  release  is  warranted  and 
can  be  undertaken,  delivery  of  the  individual  releases  on  time  and 
within  budget,  managing  the  overall  process  using  tools  for  change 
control,  traceability,  impact  analysis,  etc.,  and  modularization  of 
the  software  system  into  major  subsystems. 

And,  finally,  corresponding  to  the  lower  level  (software 
variants)  are  the  technical  concerns  relating  to  preparing  a 
complete  and  demonstrably  suitable  version  which  meets  a  set  of 
requirements.  The  process  at  this  level  must  account  for 
activities  such  as:  periodically  verifying  that  the  requirements 
are  met,  and  determining  low-level  modules  that  can  be  worked  on  by 
individuals  or  small  groups  and  that  lead  to  an  efficient 
implementation. 


2.3  Software  Life  Cycles 


Every  software  version  will  be  created  and  evolved  through 
activities  which  make  up  the  version's  life  cycle .  The  life  cycle 
starts  once  the  need  for  the  version  is  recognized  and  continues 
until  the  version  is  retired  from  service. 

Many  models  of  the  life  cycle  have  evolved  over  time.  The 
majority  of  these  primarily  pertain  to  software  releases  and 

attempt  to  discipline  the  life  cycle.  The  majority,  therefore,  are 
strongly  related  to  only  a  portion  of  the  methodological  issues 
(those  corresponding  to  releases)  and  are  prescriptive,  or  at  least 
reflective,  of  a  particular  approach  to  software  creation  and 
evolution.  A  more  generic  view  of  the  life  cycle,  pertaining  to 
all  types  of  versions  and  relatively  independent  of  any  particular 
software  creation  and  evolution  approach,  is  presented  in  this 
section  and  used  to  define  various  terms  describing  activities 

during  software  creation  and  evolution. 

Regardless  of  how  the  creation  and  evolution  process  is 

carried  out,  every  version  will  pass  through  a  sequence  of 

historical  time  points  during  its  life  cycle.  The  time  points  in 
the  history  of  many  types  of  versions  are  shown  in  Figure  2-1  and 
can  be  defined  as  follows: 

Conception:  the  first  point  at  which  a  need  for  a  version 

is  recognized. 

Definition:  presentation  of  a  possibly  rough  and 

incomplete  statement  of  the  problem  to  be 
solved  by  the  version 

Specification:  presentation  of  a  possibly  rough  and 

incomplete  description  of  the  user-visible 

features  of  the  version, 

Delivery:  presentation  of  a  believed-to-be-suitable 

version  for  integration  into  the  automated 
system 

Deployment:  presentation  of  the  version  for  actual  use. 

Freezing:  determination  that  no  further  changes  will  be 

made  to  the  version,  and 

Retirement:  removal  of  the  version  from  service. 
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These  time  points  can  be  used  to  define  the  following  activities: 


Development:  the  activity  of  preparing  a  deliverable 

version 

Installation:  the  activity  of  preparing  a  deployable 

version  from  a  delivered  version. 

Operation:  the  activity  of  using  a  deployed  version. 

Validation:  the  activity  of  analyzing  a  version  to  assure 

that  it  meets  user  needs. 

Verification:  the  activity  of  analyzing  a  version  to  assure 

that  it  meets  its  requirements. 

Corrective  the  activity  of  evolving  the  version,  after 

Maintenance:  deployment,  to  correct  deficiencies. 

This  view  of  the  life  cycle  is  pertinent,  without 
modification,  to  software  releases  since  it  has  a  strong  heritage 
in  existing  life  cycle  models.  It  is  also  pertinent  to  software 
variants  once  one  realizes  that  a  variant's  life  cycle  is  a  subset 

of  this  general  life  cycle  because  a  variant  may  Inherit  much  of 

i 1 8  detail  (in  particular,  its  specification)  from  a  previous 
variant  and  may  be  dropped  from  active  consideration  prior  to 
delivery. 

The  life  cycle  of  Figure  2.1  is  pertinent  to  a  software 
system  although  some  additional  terms  are  traditionally  used  when 
describing  a  software  system's  life  cycle.  These  terms  are 

introduced  in  Figure  2.2.  The  time  lines  at  the  top  of  this  figure 
represent  the  life  cycles  of  the  various  releases  occurring  during 
the  software  system's  life  cycle.  The  release  life  cycles  may 

overlap,  except  that:  1)  the  delivery  and  deployment  time  points 
for  the  successive  releases  are  ordered  over  time,  and  2)  the 
deployment  of  one  release  is  generally  coincident  with,  or  prior 
to,  the  retirement  of  the  previous  release. 

The  new  terms  introduced  in  Figure  2.2  are: 

Operation  &  the  activity  subsequent  to  deployment 

Maintenance:  of  the  initial  release  of  a  software 

system,  and 


Perfective  and 
Adaptive 
Maintenance : 


the  activity  of  upgrading  a 
software  system  through  new 
releases . 


The  first  is  just  a  more  explicit  name  for  "software  system 
operation"  and  reflects  common  terminology.  The  second  reflects 
the  additional  activity  of  preparing  new  releases  to  enhance  a 
software  system's  capabilities. 

Figure  2.2  highlights  a  confusion  that  frequently  arises  when 
considering  software  creation  and  evolution  activities.  Software 
system  life  cycles,  such  as  presented  in  Figure  2.2,  tend  to 
indicate  a  strong  distinction  between  software  development  and 
software  operation  and  maintenance  whereas  everyone's  intuitive 
understanding  of  these  activities  is  that  operation  and  maintenance 
typically  involves  some  development  activity.  Figure  2.2  indicates 
that  this  confusion  comes  from  not  clearly  distinguishing  the  type 
of  version  being  considered.  Operation  and  maintenance  of  a 
software  system  may,  and  typically  does,  involve  development  of 
software  releases  and  variants.  In  defining  the  details  of 
software  creation  and  evolution  activities,  one  must,  therefore, 
clearly  recognize  the  type  of  version  being  addressed  and  allow  for 
seemingly  antithetical  activities,  performed  in  creating  or 
evolving  lower-level  versions,  to  be  naturally  included  as  part  of 
the  defined  activity. 

2.4  Software  Methodology 

Many  diverse  processes  and  activities  occur  during  a  life 
cycle.  These  activities  involve  the  accumulation  of  information 
and  the  representation  of  much  of  this  information  as  software 
models.  They  also  include  the  analysis  of  the  models  and 
information  to  assess  the  system's  suitability  as  created  or 
evolved  up  to  some  point  in  time. 

A  software  method  is  a  specific  set  of  rules,  techniques  and 
guidelines  for  carrying  out  these  processes  and  activities.  Thus, 
a  method  serves  to  organize  and  discipline  the  overall  process  of 
preparing  and  evolving  the  software.  Some  software  methods  will  be 
appropriate  for  software  systems  whereas  others  may  only  be 
appropriate  for  software  variants.  For  example,  to  be  useful  for 
the  preparation  and  evolution  of  a  software  system,  a  software 
method  should  address  the  problems  of  transitioning  between 
releases. 

A  software  methodology  is  a  collection  of  methods.  There  are 
two  interpretations  of  this  definition.  On  one  hand,  the 
individual  methods  can  be  compatible  ways  of  performing  different 
activities  —  for  example,  some  can  cover  development  activities 
and  some  can  cover  operation  and  maintenance  activities  --  with  the 
result  that  the  methodology  itself  is  of  broader  life  cycle 
coverage.  On  the  ot'^er  hand,  all  of  the  methods  can  cover  the  same 
set  of  activities,  sharing  some  common  aspects  but  differing  in 
their  details.  In  either  case,  a  specification  of  the  methodology 


will  identify  those  general  principles,  practices  or  procedures 
which  are  the  basis  for  compatibility  among  the  different  methods 
or  serve  to  highlight  the  commonalities  among  the  similar  methods. 


Therefore,  a  software  methodology  is  a  general  philosophy,  or 
approach,  for  carrying  out  the  software  creation  and  evolution 
process.  It  provides  general  principles,  practices  and  procedures 
for  using  software  technology  to  prepare  and  evolve  acceptable 
software.  It  also  provides  general  principles,  practices  and 
procedures  for  using  management  technology  to  guide  the  overall 
process  to  a  timely  and  cost-effective  conclusion.  Whereas  the 
software  methodology  provides  a  general  approach  to  the 
disciplined  and  systematic  preparation  and  evolution  of  software, 
a  software  method  translates  this  general  philosophy  into  specific 
actions  to  be  performed. 

A  software  methodology  is  very  closely  related  to  the 
software  environment  providing  the  automated  and  manual  tools 
supporting  its  use.  These  tools  enforce  or  encourage  following  the 
methodology's  guiding  principles  and  using  the  methodology's 
practices  and  procedures.  A  very  important  connection  between  a 
methodology  and  an  environment  is  that  the  methodology  provides  a 
basis  for  integrating  the  environment's  tools.  By  having  all  of 
the  tools  support  a  single  methodology,  there  may  be  a  high  degree 
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However,  in  such  a 
the  way  in  which 
Therefore,  such  an 
probably  ad  hoc. 


many  features,  for 


the  creation  and 
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of  coherency  stemming  from  the  unifying  concept 
by  the  methodology.  The  connection  also 
direction.  It  is  possible  to  assemble  a  c 
without  regard  for  the  supported  methodology, 
case,  the  results  will  inevitably  constrain 
software  can  be  created  and  evolved, 
environment  will  effectively  impose  its  own, 
methodology. 

2.5  Classes  of  Methodologies 

A  software  method  or  methodology  has 
example : 

scope:  extent  to  which  it  disciplines 

evolution  of  a  software  sys 
the  individual  releases  or  vari 

potential  for  automated  support:  extent 
be  supported  by  automated  tool 

coverage:  extent  to  which  it  covers  the  f 
some  type  of  version. 

Special  names  are  sometimes  used  to 
methodologies  having  specific  scope  or  coverage 
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automated  support  potential.  For  example,  a  software  system  life 
cycle  methodology  covers  a  software  system's  full  life  cycle  and  an 
automated  development  method  provides  a  set  of  automated  tools  for 
those  activities  preceding  delivery  of  a  software  version. 

Different  types  of  methodologies  can  also  be  distinguished 
according  to  the  general  nature  of  the  approach  they  specify.  Thus 
there  are  general  classes  of  methodologies,  with  all  the 
methodologies  in  a  class  sharing  some  general  features  or 
characteristics.  Some  general  classes  of  currently  popular 

methodologies  are  discussed  in  the  rest  of  this  subsection. 

2.5.1  Product-Oriented  Methodologies 

All  methodologies  result  in  the  preparation  of  products  and 
one  approach  to  specifying  a  methodology  is,  therefore,  to  define 
these  products  rather  than  define  the  activities  used  to  prepare 
and  analyze  the  products.  Most  current  methodologies  are  examples 
of  this  product-oriented  class  of  methodologies  and  emphasize  the 
intermediate  and  final  products  produced  during  the  development 
activity. 

A  purely  product-oriented  methodology  would  specify  the 
products  but  not  the  order  in  which  they  should  be  prepared. 
However,  current  instances  of  this  class  also  divide  the  life  cycle 
into  phases,  with  the  usual  connotation  that  the  phases  are  begun 
in  a  prescribed  order  and  that  the  products  from  one  phase  should 
be  finished  and  critically  reviewed  before  progressing  to  the  next 
phase.  A  typical  set  of  phases  for  a  software  system  is  shown  in 
Figure  2.3.  The  phases  relate  to  the  time  points  in  the  li.fe  cycle 
and  indicate  the  general  nature  of  what  is  done  during  the 
corresponding  activities. 

These  methodologies  generally  do  not  specify  particular 
activities  that  should  be  performed;  rather  they  define  the 
products  that  are  to  be  produced  and  the  general  nature  of  how  and 
when  the  products  should  be  reviewed.  This  reflects  the  project 
management  heritage  of  many  product-oriented  methodologies.  The 
definition  of  the  products  and  their  review  points  is,  in  essence, 
a  definition  of  milestones  that  provide  management  insight  and 
control. 


A  typical  product-oriented  methodology  is  defined  by 
DoD-STD-SDS  for  the  development  of  DoD  software  systems  (3).  The 
general  intent  of  this  methodology  is  to  wield  management  control 
over  the  acquisition  of  a  software  release.  While  the  emphasis  of 
the  methodology  is  upon  the  initial  release,  the  methodology  is 
also  of  benefit  for  the  competitive  acquisition  of  subsequent 
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releases.  The  methodology  defined  in  DoD-STD-SDS  focuses  on 
(full-scale)  development  and  defines  the  documents  that  are  to  be 
produced  during  the  phases  shown  In  Figure  2.3.  It  also  defines 
some  of  the  details  of  the  activities  during  each  phase,  in 
particular  the  reviews  that  occur  during  and  at  the  end  of.  the 
phase.  Finally,  DoD-STD-SDS  specifies  several  auxiliary  activities 
such  as  configuration  control  and  test  management. 

2.5.2  Other  Methodology  Classes 

Since  the  idea  of  organizing  the  life  cycle  into  phases  first 
appeared  in  the  mid-1960's,  several  product-oriented  methodologies 
have  evolved  and  matured.  While  they  have  proven  to  be  generally 
useful,  some  problems  have  been  experienced.  For  example,  where 
there  is  little  experience  with  the  application  being  addressed,  a 
totally  logical  progression  from  high-level,  application-specific 
concerns  to  low-level,  implementation  concerns  has  proven  to  be 
difficult.  In  some  cases,  methodologies  that  are  more  attuned  to 
the  particular  application  have  been  found  to  be  more  effective. 
Also,  it  has  sometimes  been  difficult  to  incorporate  new  technology 
into  product-oriented  approaches  to  development.  These  problems 
have  led  to  the  introduction  of  other  types  of  methodologies  which, 
while  not  yet  as  well  developed,  have  been  receiving  a  fair  amount 
of  attention.  These  alternatives  of  course  result  in  the 
preparation  of  products,  but  focus  more  attention  on  the  techniques 
used  to  carry  out  the  process. 

Data  structuring  methodologies  are  one  example  of  these  newer 
methodology  classes.  Product-oriented  methodologies  tend  to 
emphasize  the  top-down  decomposition  of  a  system's  functionality. 
However,  data  structuring  methodologies  focus  attention  on  the 
structure  of  the  data  being  processed  and  the  composition  of 
processing  steps  that  perform  the  system's  intended  data 
transformations. 

Another  class  is  object-oriented  methodologies . 

Product-oriented  methodologies  tend  to  emphasize  development  of  the 
software  system's  functionality  and,  therefore,  are  primarily 
concerned  with  modeling  real-world  operations  in  the  software.  The 
object-oriented  approach,  on  the  other  hand,  provides  a  more 
balanced  treatment  of  objects  and  operations.  It  attempts  to 
mirror  the  problem  space  in  the  solution  space  by  identifying  the 
(data  and  non-data)  objects  of  interest  and  the  operations  which 
act  on  these  objects.  The  organization  and  operation  of  the 
software  is  described  by  modeling  the  interactions  among  objects. 
The  software  can  be  developed  either  using  composition  or 
decomposition  techniques.  . 

Another  class  of  methodologies  are  prototyping 
methodologies .  Prototyping  has  been  successfully  used  in  other 
disciplines,  such  as  engineering  and  architecture,  as  a  way  of 
coping  with  risk.  It  provides  "rough  cuts"  useful  in  determining 
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the  feasibility  and  suitability  of  emerging  solutions.  To  date, 
software  prototyping  has  primarily  been  used  to  support 
product-oriented  methodologies  as  a  way  of  clarifying  the  software 
requirements.  Through  the  prototype,  users  can  get  a  feel  for 
whether  the  system  will  satisfy  their  desires  and  expectations.  In 
turn,  the  developers  can  extend  their  understanding  of  what  the 
users  really  need. 

Prototyping  methodologies  result  from  using  prototyping  as 
the  overall  approach  rather  than  just  in  support  of  requirements 
definition.  With  such  a  methodology,  an  immature  version  is 
initially  built  and  then  gradually  elaborated  to  provide  the  full, 
required  functionality.  In  many  ways,  such  a  methodology  reflects 
what  naturally  occurs  in  software  projects. 

2.5.3  Mixtures  of  Methodologies 

The  different  methodologies  discussed  above  have  different 
emphases.  Therefore,  it  could  prove  valuable  to  use  different  ones 
for  different  aspects  of  software  creation  and  evolution.  At  the 
moment,  there  is  little  experience  in  combining  methodologies.  As 
more  experience  is  gained,  methodology  combinations  can  be  expected 
to  become  more  prevalent. 

As  an  example,  a  recent  empirical  study  (4)  has  shown  that 
prototyping  is  valuable  when  experience  in  the  application  area  is 
lacking  and  the  risk  in  being  able  to  develop  a  suitable  piece  of 
software  is  high.  The  same  study  indicates  that  product-oriented 
methodologies  are  valuable  in  producing  production-quality 
systems.  This  suggests  that  it  might  be  beneficial  to  use  a 
prototyping  methodology  early  in  a  project  and  then  switch  to  a 
product-oriented  methodology  for  later  releases. 

Different  methodologies  could  also  be  used  for  the  different 
levels  of  concern  discussed  previously.  For  example,  a  prototyping 
methodology  could  be  used  to  produce  software  variants,  whereas  a 
product-oriented  methodology  could  be  used  to  guide  the  overall 
process  at  the  software  system  level. 

2.6  Summary 

Many  approaches  are  available  for  coping  with  the  risk, 
uncertainty  and  complexity  associated  with  most  software  projects. 
The  majority  of  these  methodologies  attempt  to  provide  the  needed 
discipline  by  emphasizing  the  gradual  accumulation  of  information 
about  the  software's  operational  detail.  Others  emphasize  the  use 
of  specific  modeling  techniques  to  capture  the  Information  in 
unambiguous,  rigorous  terms.  Few  specify  concrete  techniques  for 
analyzing  the  suitability  of  this  information,  other  than  late  in 
the  project  when  the  software  is  close  to  being  operational. 


The  majority  of  current  methodologies  specify  a  set  of 
work-products  to  be  successively  (and  perhaps  iteratively) 
developed.  There  are  several  techniques  (such  as  prototyping)  and 
partial  life  cycle  methods  (such  as  object-oriented  programming) 
supporting  this  product-oriented  approach.  Concrete  methods  must 
be  defined  to  capture  these  techniques  in  a  usable  form. 

A  complete  methodology  must  address  three  major  categories  of 
concern:  those  associated  with  assuring  that  the  software  fulfills 
its  role  in  the  overall  automated  system,  those  associated  with 
preparing  software  that  meets  its  specification,  and  those 
associated  with  upgrading  the  software  to  meet  changing 
requirements.  No  current  methodologies  address  all  of  these 
concerns.  It  is  most  likely  that  a  methodology  which  addresses  all 
levels  of  concern  will  be  a  composite  with  different  methodologies 
being  used  to  address  different  concerns.  Preparing  such  composite 
methodologies  will  require  a  way  of  determining  the  differences  and 
similarities  among  methods.  Methodologies  themselves  are  a  way  of 
highlighting  differences  and  similarities  since  the  definition  of  a 
methodology  provides  an  accounting  of  the  features  common  to  all  of 
the  methods  encompassed  by  the  methodology.  By  defining 
methodology  classes,  this  highlighting  can  be  emphasized  even 
further. 

Concrete  definitions  of  methods,  methodologies  and 
methodology  classes  are  prerequisite  to  determining  the 
compatibility  information  needed  to  define  composite 
methodologies.  However,  a  concrete  definition  requires  the 
identification  of  characteristics  useful  in  making  the  distinctions 
necessary  to  set  various  methods,  methodologies  or  methodology 
classes  apart  from  each  other. 

An  appropriate  set  of  characteristics  can  also  provide  a 
basis  for  classifying  and  evaluating  methodologies  as  well  as 
selecting  among  alternative  methodologies.  The  general  nature  of 
these  technologies  is  discussed  in  the  next  section.  This  serves 
to  further  define  the  nature  of  the  characteristics  which  are 
needed  prior  to  a  discussion,  in  Section  4,  of  the  characteristics 
themselves . 


Jgi 


»i 


r* 


3.0  CLASSIFICATION,  EVALUATION  AND  SELECTION 

A  means  to  classify,  evaluate  or  select  methodologies  could 
be  used  to  support  many  activities: 

•  identifying  methodologies  for  use  on  specific  software 
proj  ects , 

•  identifying  methodologies  which  need  further  development 
to  support  some  particular  purpose,  such  as  maintenance 
in  particular  application  areas, 

•  developing  a  "consumers  guide"  to  methodologies, 

•  choosing  methodologies  for  empirical  studies  into  issues 
such  as  how  to  provide  effective  automated  support,  and 

•  qualifying  a  methodology  with  respect  to  a  set  of 
requirements. 

The  general  nature  of  methodology  classification,  evaluation 
and  selection  technologies,  and  the  process  of  developing  them,  are 
discussed  in  this  section.  The  discussion  here  concerns  their  use 
in  identifying  methodologies  for  specific  projects.  This 
orientation  has  the  benefit  of  highlighting  inter-relationships  and 
interdependencies  of  the  technologies;  it  is  not  meant  to  imply 
that  this  would  be  their  only  use. 

3 .  1  Overview 

The  three  technologies  and  their  primary  inter-relationships 
are  pictured  in  Figure  3.1.  (In  this  section's  figures,  processes 
and  activities  are  indicated  by  names  with  all  capital  letters 
whereas  information  and  knowledge  are  Indicated  by  lower  case 
names.)  The  overall  process  is  to  consider  all  possible 
methodologies  and  identify  those  acceptable  with  respect  to  the 
criteria  associated  with  a  particular  purpose.  The  major  activity 
i s  therefore  selection  of  the  acceptable  methodologies.  This 
selection  requires  two  supporting  activity:  an  evaluation  activity 
which  determines  the  "value"  of  methodologies  and  a  classification 
activity  which  determines  a  methodology's  class.  The  relationship 
among  these  activities  is  discussed  in  subsequent  sections. 

Overall  guidance  is  provided  by  criteria ,  that  is,  by 
specifications  of  need  in  terms  of  the  methodology  user's  desires. 
These  criteria  are  purpose  and  project  specific  and  for  a  project 
reflect  the  target  software's  application  area,  the  project's 
management  structure,  the  policies  of  the  contractor  and 
contracting  organizations,  and  the  basic  nature  of  the  development 
and  post-deployment  support  techniques  and  tools  used  in  the 
project.  Ideally,  the  classification,  evaluation  and  selection 
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Figure  3.1:  Selection,  Evaluation  and  Classification  Technologies 
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technologies  will  identify  a  single,  "best"  methodology.  But  more 
typically,  it  will  identify  a  collection  of  acceptable 
methodologies  and  additional  criteria  (or  subjective  analysis)  may 
have  to  be  used  to  select  a  single  methodology  from  among  the 
acceptable  ones.  Overall  support  is  provided  by  characteristics, 
that  1 8 ,  by  attributes  of  methodologies  useful  for  comparing  and 
contrasting  them.  These  characteristics  will  be  discussed  later. 

3.2  Focusing  on  Ada-Compatible  Methodologies 

Rarely  are  all  possible  methodologies  considered.  Rather, 
requirements  serve  to  reduce  the  set  of  possibilities  and  provide 
an  -initial  focus.  Since  our  Interest  is  primarily  with 
methodologies  supportive  of  the  use  of  Ada,  the  set  of  requirements 
in  this  case  serve  to  focus  upon  those  methodologies  that  can  be 
efficiently  and  effectively  used  for  Ada-based  software  systems. 
This  is  indicated  in  Figure  3.2. 

This  focus  limits  the  scope  of  the  classification,  evaluation 
and  selection  technologies  that  are  produced.  The  various 
activities  need  only  be  able  to  handle  selection  from  among 
Ada-compatible  methodologies.  The  various  pieces  of  knowledge  need 
only  pertain  to  these  methodologies.  While  the  technologies  may  be 
useful  in  considering  other  methodologies,  this  would  be  a  pleasing 
side-effect  rather  than  a  specific  goal. 

3.3  Selection  Technology 

The  activity  of  selection  identifies  those  methodologies 
meeting  the  criteria  specified  for  a  particular  project.  Selection 
can  be  performed  in  many  different  ways,  but  each  will  generally 
involve  focusing  on  a  set  of  candidate  methodologies  and  choosing 
among  the  candidate  methodologies.  These  subactivities  are 
highlighted  in  Figure  3.3. 

Focusing  narrows  in  on  a  set  of  methodologies  to  be  given 
detailed  consideration.  This  narrowing  of  attention  could  be  done 
at  any  point  in  the  process  of  identifying  acceptable 
methodologies.  It  could  even  be  done  more  than  once,  interleaved 
with  the  activity  of  choosing  among  the  methodologies  that  previous 
activities  have  identified  as  potential  candidates. 

Focusing  could  result  from  consideration  of  the  criteria.  For 
example,  the  criteria  might  specify  or  imply  that  only  prototyping 
methodologies  should  be  considered.  Alternatively,  focusing  could 
follow  from  consideration  of  factors  that  are  not  reflected  in  the 
criteria.  For  example,  an  organization  might  prepare  a  list  of 
"approved”  methodologies  and  the  choice  is  limited  to  methodologies 
from  this  list.  Therefore,  focusing  may  require  a  knowledge  of 
methodology  classes  and  a  means  of  determining  whether  or  not  a 
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specific  methodology  is  in  a  particular  methodology  class.  It  may 
also  require  the  ability  to  evaluate  an  entire  methodology  class 
without  evaluating  each  individual  methodology  in  the  class. 

Subsequently,  choosing  among  the  candidate  methodologies 
involves  evaluation  with  respect  to  the  criteria  and  interpretation 
of  the  results  to  identify  acceptable  methodologies.  Again,  many 
approaches  are  possible,  but  each  will  require  the  ability  to 
determine  the  potential  value  of  a  methodology,  or  class  of 
methodologies,  with  respect  to  the  criteria. 


3.4  Evaluation  Technology 

Selection  requires  the  ability  to 
individual  methodologies  meet  the  criteria, 
leads  to  a  need  for  measures ,  that  is,  quantita 
can  be  used  to  determine  whether  or  not  a  met 
criteria.  These  measures  can  be  obtained  by 
existing  measures  or  defining  new  ones  thro 
identification  and  definition  activity .  On 
been  Identified  or  defined,  they  can  be  used 
evaluation  activity  that  results  in  the  met 
needed  to  carry  out  selection.  These  new  piece 
highlighted  in  Figure  3.4. 
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Exactly  which  measures  to  use  in  any  particular  evaluation 
activity  may  depend  on  the  class  of  the  methodology  being  evaluated 
as  well  as  on  the  criteria.  Thus,  the  measure  identification  and 
definition  activity  will,  in  general,  provide  a  set  of  measures  to 
be  conditionally  used  depending  on  the  class  of  the  methodology 
being  evaluated. 
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critical.  (The  STARS  program  has  started  to  address  this  critical 
need  through  the  preparation  of  an  initial  set  of  measures  (5).) 

Once  measures  have  been  identified  and  defined,  evaluation 
can  be  performed.  The  basic  activity  during  evaluation  will  be  to 
determine  each  methodology's  Nvalue"  with  respect  to  the  criteria. 
Since  the  course  of  evaluation  may  depend  on  the  class  of  the 
methodology  under  evaluation,  information  about  the  various  classes 
may.  have  to  be  available  during  evaluation.  This  methodology  class 
information  may  also  allow  evaluation  to  proceed  more  efficiently 
since  it  might  be  possible  to  evaluate  entire  classes  of 
methodologies  as  a  whole. 

3.5  Classification  Technology 

The  evaluation  and  selection  of  methodologies  requires  a 
knowledge  of  methodology  classes  and  a  clan sif ication  activity 
allowing  determination  of  a  methodology's  class.  It  also  requires 
a  knowledge  of  methodology  characteristics  that  can  be  used  as  a 
basis  for  quantitative  measures.  These  final  pieces  of  technology, 
along  with  the  class  definition  activity  needed  to  develop  the 
required  knowledge  of  methodology  classes,  are  highlighted  in 
Figure  3.5. 


Methodology  characteristics  support  the  definition  of  both 
evaluation  measures  and  methodology  classes.  As  with  measures, 
these  characteristics  may  merely  be  attributes  of  the  products 
produced  by  the  methodology.  Or,  they  may  be  attributes  of  the  the 
methodology  itself,  the  developers  of  the  methodology,  or  the  users 
of  the  methodology.  For  example,  the  following  attributes  could  be 
used  in  characterizing  a  methodology:  "average  number  of  software 
modules  on  a  critical  timing  path”,  "proportion  of  real-world 
efficiency  constraints  traceable  to  units  in  software  products", 
"number  of  years  of  experience  of  methodology's  developers  in  the 
area  of  flight  control  software",  and  "required  experience  in 
application  area  needed  to  make  effective  use  of  the  methodology". 
These  examples  indicate  that  characteristics  can  be  relatively 
ill-defined,  such  as  the  last  example,  or  relatively  well-defined, 
such  as  the  third  example.  To  be  useful  in  defining  measures  of 
methodology  types,  ill-defined  characteristics  will  have  to  be 
elaborated  in  terms  of  other,  more  well-defined  ones. 

Additionally,  classification  requires  that  it  is  possible  to 
objectively  determine  the  characteristics  of  a  methodology.  Thus, 
if  a  characteristic  is  not  stated  in  measurable  terms,  it  will  be 
necessary  to  identify  the  metrics  pertinent  to  assessing  the 
characteristic  and  define  the  characteristic  in  terms  of  these 
metrics. 
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Figure  3.5:  Classification  Technology 


Criteria,  measures  and  metrics  are  seemingly  similar  terms 
that  are  used  here  in  specific  ways,  as  defined  in  the  preceding 
discussion.  To  recap  the  distinctions  which  have  been  made: 
criteria  reflect  goals  or  requirements;  whether  or  not  a 
methodology  meets  a  criteria  is  determined  by  "computing"  various 
measures  and  then  interpreting  the  values  obtained;  and  a  measure 
is  "computed"  by  determining  a  methodology's  characteristics  and 
this  is  usually  most  easily  done  by  computing  specific, 
well-defined  metrics.  Using  an  analogy  to  selecting  a  car,  the 
criteria  "economical"  is  determined  in  terms  of  the  measures  "fuel 
consumption",  among  others,  and  determining  this  measure  requires 
computing  the  metrics  "mpg,  city"  and  "mpg,  highway". 

Characteristics  may  be  used  to  define  methodology  classes  by 
defining  the  attributes  common  to  all  methodologies  in  the  class. 
The  characteristics  may  be  determined  by  identifying  some  broad 
type  of  methodologies  (such  as  prototyping  methodologies)  and  then 
determining  the  low-level,  well-defined  attributes  which 
characterize  methodologies  of  this  type.  The  set  of 
characteristics  can  therefore  be  incrementally  built  up  by 
considering  different  classes  in  turn  and  adding  any  pertinent 
characteristics  found  to  be  missing  from  the  set. 

The  classification  activity  could  be  done  once  in  preparation 
for  evaluation  or  selection,  with  periodic  updates.  Or  it  could  be 
done  as  the  results  are  needed.  Whenever  it  is  done,  it  involves 
using  the  characteristics  to  determine  the  class  or  classes  to 
which  a  methodology  belongs.  It  leads  the  person  performing  the 
classification  through  a  series  of  questions,  the  answers  to  which 
determine  the  characteristics  of  the  methodology  and  eventually 
lead  to  the  identification  of  the  methodology's  classification. 

Like  all  the  activities  discussed  above,  the  classification 
activity  may  be  empirical.  In  many  cases,  the  only  way  to  classify 
(or  evaluate  or  select)  a  methodology  may  be  by  experimentally 
using  it  in  some  trial  situations.  Ideally,  this  experimental 
usage  will  be  limited  and  involve  investigation  of  only  "small” 
systems.  However,  the  state-of-the-art  in  experimental  methodology 
evaluation  is  currently  insufficient  to  guarantee  this. 

3.6  Development  of  the  Technology 

The  preceding  discussion  of  classification,  evaluation  and 
selection  has  introduced  the  various  pieces  of  technology  in  a 
logical  order  and  uncovered  their  more  obvious  interdependencies. 
However,  it  is  unlikely  that  development  of  this  technology  will  be 
able  to  progress  "top-down”  in  the  order  presented  above.  A  major 
reason  is  that  it  will  undoubtedly  prove  valuable  to  prototype  the 
full  technology  in  order  to  understand  how  to  best  evolve  it  into 
something  more  extensive  and  useful. 


Another  major  reason  is  that  the  classification,  evaluation 
and  selection  technologies  will  likely  be  empirical  in  nature,  and 
each  will  be  needed  to  support  the  others.  For  example,  the 
definition  of  methodology  classes  may  require  the  ability  to  select 
a  methodology  to  experiment  with  or  the  ability  to  evaluate  a 
methodology  with  respect  to  some  measures.  This  leads  to  the 
secondary  dependencies  shown  in  Figure  3.6. 

Thus,  the  technology  must  be  gradually  and  iteratively 
elaborated  over  time.  Each  step  in  this  elaboration  involves: 

•  define  characteristics:  define  a  set  of  characteristics 

that  supports  the  classification,  evaluation  and 

selection  of  methodologies;  typically  this  will  be  the 
set  that  results  from  previous  technology  elaboration 
steps ; 

•  develop  a  classification  technology:  develop  a  class 

definition  procedure  and  use  it  to  define  methodology 
classes;  develop  a  methodology  classification  procedure; 
use  previously  developed  evaluation  and  selection 
technology  as  necessary;  expand  the  set  of  methodology 
characteristics  as  needed; 

•  develop  an  evaluation  technology:  define  quantitative 
measures  and  the  means  to  define  selection  criteria  as  a 
set  of  measures  to  be  evaluated;  provide  the  ability  to 
determine  a  methodology's  "value"  with  respect  to  these 
measures;  use  previously  developed  classification  and 
selection  technologies  as  necessary;  expand  the  set  of 
methodology  characteristics  as  needed;  and 

•  develop  a  selection  technology:  develop  procedures  for 

focusing  upon  candidate  methodologies  and  choosing  among 
a  candidate  set  of  methodologies;  use  previously 

developed  classification  and  evaluation  technologies  as 
necessary;  expand  the  set  of  methodology  characteristics 
as  needed. 

In  parallel  with  these  activities,  the  requirements  for 
Ada-compatible  methodologies  will  be  continuously  under 
refinement.  The  refinement  will  result  from  the  knowledge  gained 
in  developing  the  classification,  evaluation  and  selection 
technologies.  It  will  also  affect  the  development  of  these 
technologies  in  that  it  will  focus  work  on  methodologies  applicable 
to  the  development  and  post-deployment  support  of  Ada-ased  software 
systems. 


While  it  may  appear  most  logical  to  progress  through  the 
above  activities  in  the  order  in  which  they  are  presented,  this  is 
not  necessary.  In  fact,  not  all  of  them  need  to  be  completed  for 
every  step  in  the  technology  elaboration.  Each  elaboration  step 
will  result  in  a  better  understanding,  not  only  of  the  emerging 
technology,  but  also  of  the  activities  that  are  needed  to  'nature  it 
further.  Thus,  each  elaboration  step  will  provide  guidance  on  what 
to  do  at  the  next  step. 

Critical  to  all  of  the  technology  discussed  here  is  a  set  of 
characteristics  which  will  constantly  undergo  expansion  as  the 
technology  is  developed.  A  framework  is  needed  to  structure  this 
set  so  that  the  expansion  can  be  conducted  in  an  orderly  manner. 
These  characteristics,  and  their  organization  via  a  framework,  are 
discussed  in  the  next  section. 
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Methodology  characteristics  are  central  to  the  development  of 
selection,  evaluation  and  classification  technologies.  Potentially, 
there  is  a  very  large  number  of  characteristics  useful  for 
describing,  comparing  and  contrasting  methodologies.  The  set  of 
characteristics  may  potentially  never  be  complete  but  continue  to 
grow  to  reflect  the  appearance  of  new  criteria  or  the  development 
of  new  methodologies.  Consequently,  there  must  be  an  organizing 
framework  for  the  characteristics  that  can  be  extended  as  necessary 
and  easily  accommodate  new  characteristics  as  they  are  uncovered. 

A  preliminary  framework  for  organizing  methodology 
characteristics  and  a  procedure  for  enumerating  an  initial  set  of 
characteristics  are  introduced  in  this  section.  The  intent  to  date 
has  been  to  determine  the  general  nature  of  the  framework, 
systematize  the  enumeration  of  characteristics  and  populate  the 
framework  with  some  example  characteristics  sufficient  to 
demonstrate  its  effectiveness  and  rationale.  In  the  near  future, 
the  framework  will  be  used  for  some  initial  classification 
activities.  This  will  support  validating  and  further  refining 
both  the  framework  and  its  underlying  conceptual  basis. 

4.1  Overall  Structure  of  the  Characteristics  Framework 

The  characteristics  framework  provides  a  gross  organization 
for  methodology  characteristics  by  defining  four  major  categories, 
indicated  in  Figure  4.1.  These  categories  highlight  four  major 
concerns  which  arise  when  considering  methodologies  for  use  on 
Ada-based  software  projects.  As  such,  they  separate  the 
characteristics  along  the  lines  of  the  types  of  criteria  that  are 
likely  to  be  encountered. 

A  fifth  category,  automated  support,  was  suggested  by  the 
previous  work  done  by  Freeman  and  Wasserman  (1).  It  was  not 
preserved  because  it  was  felt  that  this  concern  most  naturally  cuts 
across  all  categories.  In  the  framework  described  here, 
characteristics  of  the  automated  tools  provided  by  a  methodology 
are  categorized  according  to  the  nature  of  the  support  provided  by 
these  tools.  As  a  consequence,  the  framework  makes  a  strong 
association  between  the  characteristics  of  a  methodology  and  the 
characteristics  of  the  automated  tools  supporting  use  of  the 
methodology. 

Subcategories  of  characteristics  exist  for  each  of  the  major 
categories.  The  emphasis  so  far  has  been  on  determining  the 
subcategories  within  the  technical  category.  These  particular 
subcategories  have  been  delineated  by  considering  the  different 
types  of  software  versions  and  various  approaches  for  producing 
them.  As  discussed  in  Section  2,  there  are  three  major  types  of 
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Figure  4.1: 


Characteristics  concerning  how  the 
methodology  supports  the  preparation  of 
products  having  such  desirable  properties 
as  modifiability,  efficiency,  reliability, 
understandability  and  reusability;  in¬ 
cludes  characteristics  of  the  production 
process  (such  as  resource  comsumption)  as 
well  as  characteristics  of  the  produced 
products . 


Characteristics  concerning  the  support 
which  the  methodology  provides  for 
management  activities  such  as  planning, 
tracking,  resource  allocation  and  cost 
estimation. 


Characteristics  concerning  the  process  of 
acquiring  and  using  the  methodology; 
including  activities  such  as  purchase, 
installation  of  automated  support,  usage 
monitoring,  customization,  extension 
and  training. 


Characteristics  concerning  the  methodology's 
encouragement  of  effective  use  of  the  Ada 
language  and  its  underlying  concepts. 
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software  versions  -  software  systems,  software  releases  and 
software  variants  -  and  these  help  in  distinguishing  among  various 
methodological  concerns.  Focusing  on  these  types  of  versions  and 
approaches  for  producing  them  provides  the  further  categorization 
depicted  in  Figure  4.2. 

This  figure  portrays  the  gross  structure  of  an  extensible 
framework  for  methodology  characteristics.  This  pictorial 
representation  emphasizes  that  by  focusing  attention  down  through 
the  levels  of  categorization,  one  arrives  at  a  collection  of 
characteristics  that  is  pertinent  to  that  focus.  However,  the 
strict  partitioning  of  characteristics  implied  by  the  figure  is  not 
likely  to  exist  in  practice.  It  is  expected  that  an  individual 
characteristic  will  be  pertinent  to  many  different  focuses  and  will 
therefore  appear  in  several  collections  of  characteristics.  Thus, 
the  framework  should  not  be  viewed  as  a  mechanism  for  partitioning 
the  characteristics.  Rather,  it  provides  a  means  for  categorizing 
the  characteristics  and,  as  such,  assists  in  identifying  sets  of 
characteristics  that  have  a  particular  emphasis  or  utility. 

Figure  4.2  also  emphasizes  that  the  part  of  the  framework 
receiving  the  most  attention  concerns  product-oriented  approaches 
to  producing  variants.  Some  attention  has  been  given  to  the  other 
three  major  categories  and  this  is  discussed  later  in  this  section. 

Finally,  the  figure  indicates  the  extensibility  of  the 
framework  to  accommodate  new  approaches.  Potentially,  new 
subcategories  could  be  added  anywhere  in  the  structure. 
Nonetheless,  the  expectation  is  that  the  first  two  levels  will  be 
relatively  static  and  that  future  extensions  will  lead  to 
additions  to  the  collections  of  characteristics,  the  incorporation 
of  new  sub-subcategories  within  the  technical  category  for 
additional  methodology  classes,  and  expansion  at  the  subcategory 
level  for  the  other  major  categories. 

4.2  Lower  Level  Structure  of  the  Characteristics  Framework 

The  overall  structure  of  the  characteristics  framework  serves 
to  identify  collections  of  characteristics  that  are  related  in 
terms  of  their  emphasis  on  various  concerns  or  issues.  However, 
further  detailed  organization  of  the  individual  collections  is 
needed  for  three  reasons.  First,  it  supports  understanding  how  the 
characteristics  relate  to  each  other.  Second,  it  is  needed  to 
understand  how  they  can  be  used  in  comparing  and  contrasting 
methodologies.  Finally,  the  organization  can  help  in  assuring  that 
the  collection  is  reasonably  complete.  This  subsection  discusses  an 
approach  to  organizing  collections  of  characteristics  serving  these 
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Collections  of  technical  characteristics  may  be  organized 
using  a  two  dimensional  matrix.  This  matrix  is  based  on  the  work 
reported  by  Ross,  Goodenough,  and  Irvine  (6),  and  is  shown  in 
Figure  4.3.  The  first  dimension  concerns  product  quality  goals 
such  as  correctness,  reliability  and  portability.  The  second 
concerns  general  principles  that  have  emerged  as  beneficial  in 
meeting  these  goals.  These  two  dimensions  allow  organizing  a  list 
of  characteristics  according  to  how  they  reflect  a  methodology's 
support  for  following  one  or  more  of  the  principles  to  achieve  one 
or  more  of  the  goals. 

The  matrix  can  be  used  to  structure  any  of  the  collections  of 
characteristics  found  under  the  major  category  of  technical 
characteristics.  The  definitions  for  the  goals  and  principles, 
given  in  Figure  4.3,  are  in  terms  of  software  variants  but  can 
easily  be  changed  to  pertain  to  software  releases  and  software 
systems.  Also,  the  principles  and  goals  are  common  across  many 
approaches.  Other  matrices  will  be  needed  for  the  other  three 
major  categories  since  different  concerns  and  issues  are  of 
importance  for  these  categories. 

A  possible  alternative  use  for  these  matrices  is  to  check  the 
completeness  of  a  set  of  characteristics,  or  their  associated 
metrics.  For  example,  after  inserting  the  characteristics 
developed  by  RADC  (7)  into  the  technical  matrix,  one  could  check 
their  completeness  with  respect  to  the  goals  and  principles  of 
software  engineering  as  regards  product-oriented  methodologies  and 
technical  concerns.  As  other  matrices  are  developed  for  other 
classes  of  methodologies  and  other  broad  categories  of  concerns, 
they  could  be  similarly  used  to  check  completeness  in  these  other 
situations . 

4.3  Populating  the  Framework  with  Characteristics 

Our  early  attempts  to  enumerate  technical  characteristics 
failed  because  of  the  lack  of  a  concrete  focus.  At  that  time, 
deciding  whether  a  particular  characteristic  was  pertinent  and  how 
it  related  to  other  characteristics  was  largely  an  Intuitive 
matter.  Also,  there  was  a  lack  of  consistency  in  the  definition 
and  level  of  detail  among  the  identified  characteristics. 

Experience  proved  that  three  things  were  necessary  to  support 
the  effort  of  enumerating  characteristics.  First,  it  was  useful 
to  narrow  attention  to  a  specific  major  concern  (such  as  technical 
issues)  ,  a  specific  type  of  software  version  (such  as  software 
variants),  and  a  specific  class  of  approaches  for  developing  the 
version  (such  as  product-oriented  approaches).  Second,  it  was 
useful  to  consider  methodology  characteristics  in  terms  of  how  the 
methodology  supports  the  use  of  modern  software  technology 
principles  (like  information  hiding)  to  achieve  results  with 


various  quality  attributes  (such  as  reliability).  Third,  it  was 
helpful  to  think  in  terms  of  various  objectives  that  serve  to  meet 
quality-related  goals  but  rely  on,  or  relate  to,  one  or  more  of  the 
modern  software  technology  principles. 

The  first  two  experiences  led  to  the  framework's  gross 
structure  and  the  characteristic  organizing  matrices, 
respectively.  The  third  led  to  developing  an  approach  for 
enumerating  characteristics  to  populate  the  various  cells  in  the 
matrices.  It  must  be  emphasized  that  this  is  only  one  possible 
enumeration  approach  which  has  been  found  particularly  helpful  in 
initially  populating  the  matrices  with  characteristics.  Other 
approaches  —  such  as  scanning  independently  developed  lists  of 
characteristics  or  taking  note  of  characteristics  during 
demonstrations  or  experiments  --  may  prove  more  useful  in  the 
future  when  the  task  will  shift  to  expanding  the  set  of 
characteristics  rather  than  determining  an  initial  set. 

The  enumeration  approach  consists  of  considering  each  goal  in 
turn,  determining  the  objectives  that  support  meeting  this  goal, 
converting  these  objectives  into  characteristics  and  then  placing 
these  characteristics  into  the  cells  corresponding  to  the 
principles  that  support  meeting  the  identified  objective.  The  first 
two  columns  of  Figure  4.4  show  the  results  of  carrying  out  the 
first  three  of  these  steps  for  technical  characteristics  pertinent 
to  the  goal  of  efficiency  and  the  production  of  software  variants. 
The  right-hand  column  of  Figure  4.4  indicates  which  cells  in  the 
efficiency  column  would  receive  the  enumerated  characteristics  when 
they  are  placed  in  the  technical  matrix. 

While  these  characteristics  were  enumerated  within  the 
context  of  product-oriented  methodologies,  the  result  can  be 
expected  to  be  pertinent  to  most  other  methodology  classes.  This 
re-emphasizes  two  previously  made  points.  First,  the  matrix  for 
technical  characteristics  is  relatively  independent  of  the 
methodology  being  considered  since  the  matrix  is  founded  on  the 
goals  and  principles  which  must  be  achieved  and  utilized, 
respectively,  by  any  methodology.  Second,  the  enumeration  approach 
1 8  useful  for  determining  an  initial  set  of  characteristics  and 
other  approaches  may  be  more  useful  for  expanding  this  initial  set. 

While  use  of  this  enumeration  approach  is  primarily  for 
determining  an  initial  set  of  characteristics,  the  focus  on 
objectives  does  have  two  beneficial  side-effects  which  may  expand 
its  utility.  First,  since  objectives  tend  to  imply  some 
measurement,  characteristics  which  are  derived  from  objectives  are 
themselves  likely  to  be  measurable.  Additionally,  the  eventual  use 
of  the  characteristics  framework  in  selection  activities  and  for 
providing  a  terminology  for  stating  requirements  of  methodologies 
makes  this  orientation  towards  objectives  potentially  doubly 
useful. 
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It  is  critically  necessary,  when  using  this  enumeration 
approach,  to  do  the  seemingly  redundant  step  of  converting  the 
objectives  into  unbiased  characteristics.  It  is  the  nature  of  an 
objective  to  include  some  bias,  for  example,  "Minimize  complexity 
of  ..."  or  "Localize  the  scope  of  ...".  Whereas,  a 
characteristic  should  be  an  unbiased  statement  such  as  "Degree  of 
complexity  of  ..."  or  "Extent  of  scope  of  ...".  This  lack  of  bias 
is  necessary  since,  in  some  situations,  it  may  be  desirable  to 
compromise  a  particular  objective  so  that  another  can  be  optimized. 

It  is  also  critically  necessary  to  determine,  as  illustrated 
in  Figure  4.4,  subobjectives  down  to  a  level  leading  to  measurable 
characteristics.  While  many  characteristics  are  directly 
measurable,  some  will  not  be.  For  example,  several  relatively 
well-established  metrics,  such  as  Halstead's  Software  Science 
metrics  or  McCabe's  Complexity  metric,  can  be  used  to  evaluate  the 
characteristic  "degree  of  complexity  of  software  structures". 
However,  the  characteristic  "extent  to  which  software  structure 
supports  achieving  efficiency  constraints"  cannot  be  easily 
measured  directly  and  the  objective  from  which  it  stems  must  be 
successively  decomposed  until  subobjectives  are  reached  that  lead 
to  measurable  characteristics. 

A  knowledge  of  metrics  is,  therefore,  crucial  to  identifying 
characteristics.  The  metrics  work  done  by  others,  such  as  at  RADC 
(6)  and  within  the  STARS  Measurement  area,  will  of  course  be 
critical  in  both  guiding  the  enumeration  of  characteristics  and 
suggesting  characteristics  which  are  not  uncovered  by  enumeration 
approaches  such  as  discussed  here. 

The  enumeration  approach  is,  in  essence,  table-driven  and  can 
be  used  to  identify  and  organize  an  initial  set  of  characteristics 
in  other  categories.  The  matrices  for  these  other  categories, 
discussed  in  the  next  subsection,  can  be  used  to  drive  the 
enumeration  approach  in  order  to  identify  characteristics  pertinent 
to  these  other  categories. 

4.4  Defining  the  Scope  of  the  Other  Categories 

The  organizing  matrix  shown  in  Figure  4.3  reflects  the  goals 
and  principles  of  software  engineering.  It  relates  to  the 
technical  aspects  of  a  methodology  and,  therefore,  is  most  useful 
in  identifying  and  organizing  the  technical  category  of 
characteristics. 


Similar  matrices  for  other  categories  can  be  obtained  by 
replacing  the  goals  and  principles  with  those  of  the  other 
categories  of  concern.  Organizing  metrices  have  been  defined  in 


The  management  category  addresses  the  planning,  organizing 
and  controlling  of  software  projects.  This  area  of  concern  involves 
consideration  of  both  the  management  of  software  products  and  the 
people  involved  in  the  software  creation  and  evolution  process. 
Consequently,  the  matrix  reflects  both  purely  managerial  issues, 
such  as  staff  scheduling,  and  more  technically  influenced  issues, 
such  as  measuring  progress  against  pre-defined  milestones.  This 
matrix  is  shown  in  Figure  4.5. 
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This  final  matrix  reflects  how  a  methodology  supports 
effective  use  of  specific  Ada  language  features.  This  cannot  be 
done  in  isolation  of  considering  how  these  language  features  are 
being  used.  For  example,  the  use  of  representation  specifications 
for  developing  software  to  control  peripheral  devices  will  be 
different  from  their  use  in  developing  pattern  recognition 

software.  Therefore,  the  Ada-compatibility  matrix  uses  major 

software  functions  for  its  goals  and  the  chief  Ada  language 
constructs  for  its  principles.  Software  functions,  such  as 
peripheral  control  and  process  control,  are  used  in  preference  to 
application  areas,  such  as  ballistic  missile  systems  and  C3  systems 
since  they  tend  to  be  better-defined  and  more  specific,  whereas 
application  areas  typically  involve  a  variety  of  different  software 
functions.  Thus,  this  matrix  supports  identifying  and  organizing 
characteristics  which  describe  how  a  methodology  supports  use  of 
each  language  construct  in  developing  different  types  of  software 
functions . 
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figure  4.7:  Preliminary  Matrix  for  Collections  of  Ada  Compatibility  Characteristics 


4.5  Current  Status  of  the  Characteristics  Framework 


The  technical  matrix  and  enumeration  approach  have  already 
been  used  to  identify  some  initial  technical  characteristics.  This 
Initial  set  of  characteristics  is  incomplete.  In  particular,  the 
decomposition  of  objectives  to  subobjectives  is  not  exhaustive  and 
further  decomposition  will  result  in  the  identification  of 
additional  characteristics.  In  the  near  future,  the 
characteristics  framework  will  be  extended  to  include  additional 
collections  of  characteristics  in  the  technical  category  and  to 
cover  the  other  major  categories.  This  framework  will  continue  to 
evolve  over  a  span  of  several  years  as  understanding  of  the 
software  development  and  evolution  process  grows  and  new  types  of 
software  methodologies  are  developed. 


5.0  SUMMARY 


This  document  provides  a  basis  for  discussing  the  concerns 
and  issues  of  software  methodology,  identifies  the  pieces  of 
technology  needed  to  be  able  to  classify,  evaluate  and  select 
among  software  methodologies,  and  introduces  a  flexible  framework 
for  organizing  the  myriad  detailed  characteristics  needed  to 
support  these  technologies.  It  provides  few  solutions  but, 
instead,  defines  the  dimensions  of  the  problems  surrounding 
software  creation  and  evolution  and  the  general  nature  of  the 
solutions.  As  such,  it  lays  a  groundwork  for  rationally  obtaining 
and  using  the  technology  critically  necessary  for  the  disciplined 
creation  and  evolution  of  software. 
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Adaptive 
Maintenance : 

Analysis : 

Automated  Software 
Environment : 

Automated  System: 

Characteristic : 

Characteristic 
Framework : 

Classification: 

Coding  : 

Conception : 

Corrective 
Maintenance : 

Coverage : 

Criteria : 


maintenance  performed  to  make  a 
software  version  usable  under  a  changed 
set  of  requirements 

the  activity  of  determining  whether  or 
not  a  software  version  is  suitable 

a  collection  of  tools  that  assists  the 
process  of  creating  and  evolving 
software 

a  system  composed  of  hardware,  software 
and  human  components 

see  Methodology  Characteristic 

a  structure  for  categorizing 
characteristics 

determining  the  characteristics  of  a 
methodology  and  what  these 
characteristics  imply  about  its  general 
type 

the  phase  in  the  life  cycle 
during  which  data  or  a  software  version 
is  represented  in  a  symbolic  form  that 
can  be  accepted  by  a  processor 

the  point  in  time  at  which  there  is  an 
initial  perception  of  need  for  a 
software  version 

maintenance  performed  to  overcome 
identified  faults 

extent  to  which  a  methodology  covers  the 
full  life  cycle  of  some  type  of  version 

use-oriented,  high-level  attributes 
useful  in  deciding  acceptability 


Data  Structuring 
Methodology : 


methodology  that  focuses  initial 
attention  on  the  definition  of  system 
inputs  and  outputs 


Definition 


Delivery : 

Deployment : 

Detailed  Design: 

Development : 

Evaluation : 
Freezing  : 

Implementation : 
Installation : 

Life  Cycle: 


the  point  in  time  at  which  a  software 
version  is  described  by  a  document 
defining  the  problem  to- be  solved  and 
the  general  nature  of  and  requirements 
upon  its  solution 

the  point  in  a  life  cycle  at 
which  a  software  version  is  released 
for  integration  into  the  automated 
system  of  which  it  is  a  part 

The  point  in  a  life  cycle  at 

which  a  software  version  is  released 

for  operational  use 

the  phase  in  a  life  cycle  during  which  the 
preliminary  design  is  refined  and  expanded  to 
contain  more  detailed  descriptions  of  the 
processing  logic,  data  structures,  and  data 
definitions,  to  the  extent  that  the  design  is 
sufficiently  complete  to  be  implemented 

the  process  by  which  user  needs  are 
transformed  into  a  software  version 
that  can  be  delivered 

determining  whether  a  methodology  meets 
certain  criteria 

the  point  in  a  life  cycle  at  which  it 
is  decided  that  no  further  changes  will  be 
made  to  an  operational  software  version 

see  coding 

the  process  by  which  a  software  version 
is  integrated  into  its  operational 
environment  and  tested  in  this 
environment  to  ensure  that  it  performs 
as  required 

the  period  of  time  frcm  the  Initial 
perception  of  need  for  a  software 
version  to  its  retirement 


Maintenance 


Measure : 

Method : 

Methodology : 

Methodology 
Characteristic : 

Metric : 

Model : 

Obj  ect : 

Obj  ect -Oriented 
Methodology : 

Operation : 

Operation  and 
Maintenance : 


modification  of  a  software  version  after 
delivery  to  correct  faults,  improve 
performance  or  other  attributes,  or 
meet  new  requirements 

a  quantity  that  can  be  evaluated  to 
determine  whether  or  not  a  methodology 
meets  a  particular  criteria 

a  set  of  rules,  guidelines,  and 
techniques  for  carrying  out  a  process 

a  general  philosophy  for  carrying  out  a 
process;  comprised  of  procedures, 
principles,  and  practices 

a  detailed  attribute  that  can  be  used  to 
describe  a  methodology 

a  quantity  that  can  be  evaluated  to 
determine  whether  or  not  a  methodology 
has  a  particular  characteristic 

a  representation  which  specifies  some 
but  not  all  of  an  entity’s  attributes 

an  encapsulation  of  data  and/or 
processing  activity  which  reflects 
some  entity  in  the  software  or  its 
operational  environment 

a  methodology  that  represents  the 
organization  of  a  piece  of  software  as 
a  layering  of  successively  more  detailed 
obj  ect  8 

use  of  a  version  in  its  operational 
environment 

use  of  a  software  system  in  its 
operational  environment;  involves 
monitoring  for  satisfactory  performance 
and  modification  as  necessary  to  correct 
problems  or  respond  to  changed  require¬ 
ments 


Perfective 
Maintenance : 


maintenance  performed  to  Improve 
performance,  maintainability,  or  other 
software  attributes 


Phase  : 

Product-Oriented 
Methodology : 


Post -Deployment 
Support : 

Preliminary  Design: 


Product : 
Prototype : 

Prototyping 
Methodology : 

Release : 

Requirements 
Definition : 


a  period  of  time  during  a  life  cycle 

a  methodology  that  is  defined  primarily 
by  specifying  the  intermediate  and  final 
products  to  be  produced;  definition  of 
the  products  is  usually  accompanied  by 
the  definition  of  phases  where  each 
phase  is  focused  on  the  preparation  of 
one  or  more  of  the  products 

see  Maintenance 


the  phase  in  a  life  cycle  during  which 
alternatives  are  analyzed  and  the  general 
architecture  of  a  software  version  is 
defined;  typically  includes  definition  and 
structuring  of  modules  and  data,  definition 
of  interfaces,  and  preparation  of  timing  and 
sizing  estimates 

results  created  by  a  process 

an  instance  of  a  software  version  that 
does  not  exhibit  all  the  properties 
of  the  final  system;  usually  lacking  in 
terms  of  functional  or  performance 
attributes 

a  methodology  that  organizes  the 
creation  and  evolution  of  a  software 
version  as  a  series  of  prototypes 

a  software  version  that  is  delivered  for 
integration  into  an  automated  system 

the  phase  in  the  life  cycle  during 
which  the  requirements,  such  as  the 
functional  and  performance  capabilities, 
are  defined 


Retirement : 

Scope : 

Selection : 

Software : 

Software  System: 
Specification : 

Technology : 

Test  and 
Integration : 

Tool : 

Variant : 

Validation : 

Verification : 


the  point  in  a  life  cycle  at  which  a  software 
version  is  removed  from  service 

extent  to  which  a  methodology  disciplines  the 
creation  and  evolution  of  a  software  system 
rather  than  just  the  individual  releases  or 
variant  s 


picking  a  methodology,  or  set  of  alternative 
methodologies,  for  use  on  a  specific  project 


the  executable  code,  all  of  its  associated 
documentation  and  documents  that  trace  the 
history  of  its  creation  and  evolution 


a  component  of  an  automated  system  that  is 
realized  as  executable  code 

the  point  in  time  at  which  a  version  is 
described  in  a  document  that  defines,  in  a 
relatively  complete,  precise,  and  verifiable 
manner,  the  requirements  of  a  software 
version 

collection  of  techniques  and  knowledge 
underlying  some  process 

the  phase  in  a  life  cycle  during  which  the 
conformance  of  the  version  to  its 
requirements  is  assessed  and  the  version  is 
integrated  into  the  larger  (software  or 
automated)  system  of  which  it  is  a  part 

software  which  assists  in  carrying  out 
a  task  or  activity 

any  of  those  versions  of  a  software 
system  which  are  prepared  in  the  course 
of  developing  a  release 

analyzing  a  version  to  assure  that  it 
meets  user  needs 

analyzing  a  version  to  assure  that  it 
meets  its  requirements 


Version : 


any  instance  of  a  software  system 
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